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Abstract: 

An ad hoc network is a collection of wireless 
mobile nodes dynamically forming a tempory 
network with out the presence of a wired support 
infrastructure. In this environment, 
routing/multicasting protocols are faced with the 
challenge of producing multi-hop routes under 
host mobility and bandwidth constraints. In 
recent years, a number of new multicast protocols 
of different styles have been proposed for ad hoc 
networks. ODMRP (On Demand multicast 
routing protocol) is a mesh based, rather than a 
conventional tree based , multicast scheme it well 
suited for adhoc wireless networks. ODMRP has 
been simulated on PARSEC and its performance 
evaluated wehave implemented ODMRPon ns-2 
and have done a simulation based performance 
analysis. Based onour experience during 
implementation, we have also suggested some 
enhancements to the protocol which we believe 
improve its performance. 


1. Introduction: 

An adhoc network is a dynamically reconfigurable 
wireless network with no fixed infrastructure or 
central administration. In a typicalad hoc 
environment network hosts work in groupsto carry 
out a given task .Hence multicast plays akey role in 
ad hoc networks . protocols used instaticnetwork: 
MOSPF[M94], = PIM[DE96], DBMRP[DC90], 
CBT[BFC93]), However , do not perform well in a 
dynamically adhoc network environment. Multicast 
tree structure orfragile and must be readjusted 
continuously has connectivity changes. Furthermore, 
typical multicast trees usually require global routing 
sub structure such has linkstate or distant vector. The 
frequent exchange of routing vectors or linked state 
tables, triggered by continuous topology changes, 
yields excessive channel and processing overhead. A 
mobile adhocnetworking (MANET) working group 
has been formed within the Internet Engineering 
TaskForce (IETF) to develop a routing frame work 
for IP based protocols in adhoc networks. 

On demand Multicast RoutingProtocol 
(ODMRP) is amesh based multicast routing protocol 
for ad hoc networks. It has been implemented and its 
performance has ben analyzedon PARSEC[BM98]. 
Areal system implementation of ODMRP has also 
been doneon the Linux Kernel version 2.0.36 
[LS G99]. Ourgoal was to implement ODMRP on the 
network simulatorns-2[FV97], carry out a 
performance study and compare the results with 
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those obtained on PARSEC. This also enabledus 
togain an understanding of the issues involved 
inimplementing and simulating a wireless protocolon 
ns. We intend to integrate our implementation with 
the standard ns distribution there by making it 
available to the research community. ODMR 
Pwassimulated in diverse network scenarios .We 
studied the impact of mobility on performance by 
varying the speed of network hosts. Different 
multicast group sizes were simulated to investigate 
the impact on performance. We apply metrics that 
shows the “efficiency? in addition to the 
“effectiveness” for the protocol.2. Background: 

In this section, we first give taxonomy of multicast 
adhoc routing protocols. Then we briefly describe the 
working of ODMRP. Finally, we give a brief 
introductiontons-2. 

2.1 A Taxonomy of Multitude Ad-hocProtocols : 


There exists a multitude of multicast protocols 
(AMRoute[BLAT98], AMRIS[WTT98], 
CAMP[GM99], MAODV[RP99], ODMRP[LSG99]) 
for ad hoc networks (hence forth referred to as 
multicast protocols). Based upon their routing 
techniques and forwarding methods multicast 
protocols can be categorized in following ways: 


®Routingtechniques 


1. On demand routing: The routes are 
discovered and updated as and when needed .In other 
words, whenever a sourcehas some data to send and 
does not already route to the destination, it initiates a 
route discovery. There are nolonglived routing tables 
to make instantaneous routing decisions. 


2. Not on demand Routing: This type ofrouting 
is very similar to static routing in wirednetworks 
where routing tables are periodicallyupdated. 


® Forwardingtechnique: 


1. Tree based multicast: members of a 
multicast group are organized in a tree like structure. 
Information from the source node flows to its parent 
and towards the root, each node in turn disseminates 
multicast message to its other children. 


2; Mesh-based multicast: Members of 
a multicast group form a mesh like structure with 
redundant links between apair of hosts. Amesh 
supports shortest paths between any member pair. 
The mesh provides a richer connectivity among 
multicast members compared to tree. 


The key motivation behind the design of ondemand 
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protocols is the reduction of therouting load.High 
routing load usually has asignificant performance 
impact in lowbandwidth wireless links.Hence on 
demandroutingisa highlydesirable feature ofany 
outing protocol for adhoc networks. In a mobile 
scenario, mesh based protocols have been claimed 
to out perform tree based protocols [LSHGBOO]. 
Among them ,the on demand mesh based 
multicast routing protocol, ODMRP [LGC99,LSG99] 
has been claimed to be highly effective and efficient 
in all adhoc network scenarios. 

ODMR Pcreatesamesh of nodes (the forwarding 
group) which forward multicast packets via flooding 
(within the mesh), thus providing path redundancy. 
ODMRP is on —demand protocol, thus it does not 
maintain route information permanently 
Ituses a soft state approach in group 
maintenance. Member nodes are refreshed as needed 
and do not send explicitleavemessages. 

In ODMRP group membership and multicast routes 
are established and updated by the source on 
demand. Figureldepicts this process .Similar to on 
demand unicast routingprotocols, a request phase and 
a reply phase comprise the protocol. When multicast 
sources have data to send, but do not having routing 
or membership information, they flood a JOIN 
QUERYpacket. When a node receives a nonduplicate 
JOINQUERY it stores the upstream node ID and 
rebroadcasts the packet. Whena JOINQUERY 
packets reaches a multicast receiver, the receiver 
creates a JOINREPLY and broadcasts to the 
neighbours. When anodereceive JOINREPLY it 
checks if then extnode ID of on eoftheentries 
matches its own ID.If itdoes, the node realizes that it 
is on the path tothe source and thus is part of the 
forwarding group. It then broadcasts its own 
JOINREPLY builtup on match edentries. 


The JOIN REPLY is thus propagated by each 
forwarding group member until it reaches the 
multicast source via the shortest path. This 
processconstructstheroutesfromsourcestorecei versand 
buildsameshofnodes,theforwardinggroup.Multicastre 
nders refresh the membership information and update 
the routes by sending JOINQUERY periodically 

We use the ns network simulator [FV97] to do our 
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simulation of ODMRP. ns is a discrete event 
simulator developed by the university of California at 
Berkeley and the VINT project.It is target edat 
networking research. It is an object simulator, written 
in c++, with an OTcl interpreteras the front end. The 
back end is used for varying parameters or 
configurations during the simulations of the 
protocols. The OTcl front endis used for varying 
parameters or configurations during the simulation. 
The Monarch project at CMU extended ns 
[BMJHJ98] to allow simulation of pure wireless 
LANs ormulti-hop adhoc networks. The extensions 
include: 

®Nodemobility. 


®Area listic physical layer including a radios 
propagation model supporting propagation delay, 
capture effects, and carriersense[R95]. 


®Radio networking interfaces with propertiessuch as 
transmission power, antennagain, and receiver 
sensitivity. 


®TheIEEE802. 1 1 MediumAccessControl(MAC) 


3. Design: 
In this section we first describe the basic 
wirelessmodelin ns.We thendescribe our 


modification to the basic model for implementing 
ODMRP. 


Figure2 shows the model of a basic wireless mobile 
node in ns. Each mobile node makes useof a routing 
agent for the purpose of calculatingroutes to other 
nodes in the hoc network.Packetsare sent from the 
application and are received by the routing agent. 
This decides a path that the packet must travel to 
reach its destination.It thensends the packet down to 
the link layer.The linklayer uses an address 
Resolution Protocol(ARP)to decide the hardware 
address of neighboring nodes and mapIP addresses to 
the ircorrect interfaces. 


When this information is know,the packet is 
sentdown to the interface queue and awaits a signal 
from the MAClayer. When the MAC layer decides it 


is ok to send it onto the channel, it fetches the packet 
from the queue and hands itoverthe network interface 
which in turn sendsthe packet onto the radio channel. 
This packet iscopiedand is delivered to all network 
interfacesat the time atwhichthe firstbitof the 
packetwith the receiving interfaces properties and 
theinvokes the propagation model.The propagation 
modeluses the transmit and receive stamps 
todetermine the power with which the interface 
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willreceive the packet. The receiving interface 
thenuses the packetsproperties to determine if it 
successfully received the packet, and sends it tothe 
MAC layer if appropriate. If the MAC layerreceives 
the packeterror-free and collision-free, it passes the 
packet to the mobile node’s entry point. From there it 
reaches a de multiplexer, that decides if the packet 
should be forwarded again ,or if it has reached its 
destination node. If the destination node is reached 
„the packet is sent to aport demutiplexer which 
decides the application to which the packet should be 
delivered. If the packet should beforwarded again,the 
routing agent will be called and the procedure will be 
repeated. 


We make the ODMRP agent the entry point ofthe 
node. This enables the agent to overhear allthe 
packets on the channel by tapping into the 
MAClayer. This is needed to support the passive 
acknowledgement feature of ODMRP which enables 
there liable delivery of JOINREPLAY messages. 

4 Implementation Details: 


We have implemented ODMRP according to 
theIETF draft specification [LSG99]. The following 
points are worth nothing. 


® We have not assumed GPS capability for 
mobilenodes. 


® The timers used for all ODMRP simulations 
are gi venabove. 


® Join Replay Propagation:The specificationallows 
for any method of reliable delivery of 
JOINREPLAY(e.g., explicit acknowledgments, 
passive acknowledgments, unicast). We chose to 
unicast theJOIN REPLAY messages because we can 
takeadvantage of the IEEE 802.11 MAC reliable 
transfer mechanism. 


®We have also implemented the unicast version of 
ODMRP. 


In order to verify that our implementation meets 
those specifications of the protocol, we developed 
validation suite.The validation suite was written in 
OTcl and covered most of the scenarios tha tarise. In 
addition to this, the source code of the 
implementation was independently validated by two 
of the authors. 


5. Protocol Enhancements: 


In this section we describe some of our 
enhancements to the protocol as specified in the 
IETE draft.While implementing ODMRP, we faced 
some implementation issues. These issues arise 
because the specification of the protocol isnotclear 
on certainaspects.The enhancements discussed in this 
section resulted from our solutions to these issues. 
We believe that these enhancements improve the 
performance of theprotocol. 
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5.1 JOINT QUERYjitter: 


An ODMRP agent on receivinga JOINTQUERY 
broadcasts it., Node Abroad casta JOINT QUERY 
and notes B and C receive it at the same time. Now, 
Band C rebroadcast the JOINQUERY in overlapping 
times which results in a collision. Thus node D , 
which canonly get a JOINT QUERY from B or C, 
does not receive the JOINT QUERY and any node 
that depends on D to forward packets is effectively 
cutoff from the multicast group. 


To solve this problem we introduced a small random 
jitter during the broadcast of a JOIN QUERY. This 
greatly improved the effectiveness of theprotocol. 


5.2 JOINREPLY Implosion: 


According to the specification of ODMRP, when a 
node in the forwarding group receives a 
JOINREPLY message, i tshould forward it towards 
the source. So, when there are many nodes. In the 
multicast group, this will lead to what we call the 
“JOINREPLY Implosion” problem, similar to the 
ACK/NACK Implosion problem in multicast 
protocol [FJLMZ97]. To solve this problem, each 
node maintains an extra flag and a corresponding 
time rinits forwarding groupcache. Whenever a node 
sends a JOIN REPLY towards the source it sets this 
flag and the timer and nomore JOINREPLY 
messages are sent if the flag is set. Theflag is reset 
when the timer expires. The valueof this timer is set 
to be less than the JOINREFRESHINTERVAL. 


6. Simulationmodelandmethodology: 

Our simulation modeled a network of 50 mobilehosts 
placed randomly within a 1000 m*1000 m area. 
Radio propagation range for each node was 250 
meters and channel capacity was 2Mbits/sec. The 
multicast groups varied in size with eachgroup 
having one source sending at a rate of 20 
packets/sec.Each simulation executed from 300 
seconds of simulation time Multiple runs 
withdifferentseednumbers wereconductedforeachscen 
ario and collected data was averaged overthoseruns. 


6.1 MediumAccessControl Protocol: 


The IEEE 802.11 MAC with Distributed 
Coordination Function (DCF)[IEEE97] was used as 
the MAC protocol.DCF is themode which allows 
mobiles to share the wireless channel in an hoc 
configuration.The Specific access schemeis Carrier 
Sense Medium Access/CollisionA voidance 
(CSMA/CA) with acknowledgements. Optically,the 
nodes can make use of request To send/clearTo send 
(RTS/CTS) channel reservationcontrolframes for 
“unicast” ,and virtual carrier sense. By setting timers 
basedupon the reservations in RTS/CTS packets, 
the virtual carrier sense augments the physical 
carrier sense in determining when mobile nodes 
perceive that the medium isbusy. According to the 
specification, JOINREPLY messages must be 
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reliably transmitted. We employ § RTS/CTS 
exclusively to reliably unicast JOINREPLY 
messages directly to specific neighbours. All other 
transmissions useCSMA\CA. 


6.2 ChannelandRatioModel 

The radio model uses characteristics similar to a 
commercial radio interface, Lucents wave 
LAN[ES96],[T93]. WaveLAN is a shared media 
radio with a nominal bit-rate of 2 Mb/sec and a 
nominal radio range of 250 meters. A detailed 
description of simulation environment and the 
models is available in[BMJHJ98],[FV97]. 


6.3 Trafficpattern: 


We use constant bit rate (CBR) sources.The sizeof 
the datapayloadwas 512bytes.The senderwas chosen 
randomly among multicast members who inturn were 
choosen with uniformprobability among 50 network 
hosts. The member nodes join the multicast session 
at the beginning of the simulation and remains as a 
members throughout the simulation. 


6.4 Mobilitymodel: 


The mobility model uses a random waypointmodel 
[BMJHJ98] in a rectangular field of 1000mX 1000m 
with 50 nodes.Here each node starts itsjourney from 
a random location to a randomdestination with a 
randomly chosen speed. Notethat this is a fairly high 
speed for ad hocnetworks,comparerable to a traffic 
speeds inside acity .Once the destination is reached, 
anotherrandom destination is targeted after a 
pause.pass time,which affectsthe relative speedsof 
themobiles ischosenrandoml ybetween0-10sec.When 
the node reaches the simulation terrain boundary, it 
bounces back and continues to move. 

6.5 Performancemetrices 


We have used the following metrices to evaluate the 
performance of ODMRP.. These metrics were 
suggested by the IETF MANET workinggroup for 
routing /multicasting protocolevaluation[CM99]. 


®PacketDeliveryratio: 

The ratio of the number of the data packets actually 
deliver to the destinations versus the number of data 
packets supposed to be received. Packet delivery 
ratio is important as it describes the loss rate that will 
be seen by the transport protocol, which in turn 
affects the maximum throughput that the application 
perceives. 

®DataTransmitRatio: 

The ratio of the number of data packets transmitted 
per datapacket actually delivered. Datapackets 
transmitted is the count of every individual 
transmission of data by each node over the entire 
network. This coun tincludes transmission of packets 
that are eventually dropped and re transmitted by 
intermediate nodes. Note that unicast protocol this 
measure is alwaysequal to or greater than one. 
Inmulticast, inceasing letransmission can deliver data 


to multiple destinations, the measure can be less than 
one. 

®Control Overhead:The ratio of the number of 
control by testransmitted per data byte delivered. 
Instead of usin game asure of the pure control over 
head, we chose touse the ratio of control by 
testransmitted to databytes delivered to investigate 
how efficiently control packets are utilized in 
delivering data. Note that not only bytes of control 
packets but also bytes of data packets of headers are 
included in the number of control by testransmitted 
„Accordingly , only the data payload bytes contribute 
to the data bytes delivered. 

The first metric above characterizes the 
‘Effectiveness’ of the routing protocol while these 
condand third metrics characterize the ‘Efficiency* of 
the protocol. 


Node mobility []Random waypoint model, bounce back into the field if a boundary is 
encountered. 
Speed Arandom value between 0 anda predefined maximum, where the 
maximum varies in the range [0,20] m/s 
Traffic type Constant bit rate 
Data packet payload 512 bytes 
Data packet header 28 byte (IP header : 20 sequence number : 4,identification number : 
Join Query size 40 bytes(IP header : 20,routing information : 20)+Data payload 
Join reply size 40 bytes (IP header ; 20, join table : 20) 
Parameter Value 
Number of nodes 50 
Field area 1000m X 1000m 
Field area 1000m X 1000m 
Simulation duration 300 secs 
Transmitter range 250m 
Channel Bandwidth 2 Mbits/s 
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SimulationResults: 


7.1 Packet delivery ratio: The size of the multicast 
group is varied to examine the scalability of the 
protocol. The result indicates that ODMRP delivers a 
high portion of data packets in most of our scenarios 
In highly mobile situations, the performance is least 
effective in two membercase.Having only two multi 
cast members corresponding to a unicast situation. 
When ODMRP functions as a uncastprotocol, a mesh 
is not formed and there is no redundancy in packet 
for warding. Since there are no multiple routes, the 
probability of packet drop increases with mobility 
speed. As the number of members increases, the 
forwarding mesh group creates a richer connectivity 
among members. We can see from the result that 
ODMRP delivers over 87% of multicast packets in 
the face of high mobility. 


7.2 Control Overload: 

We can see that ODMRP efficiently utilizes control 
packets in delivering data. As expected, the 
efficiency improves as the number of multi cast 
members grows larger. 


73 Transmission Overhead: 

The average number of total packets transmitted per 
data byte delivered, the number remainsr elatively 
constant with varying speed and protocol Becomes 
more efficient when more multicastmembers 
exist. The result shows the channel efficiency of 
ODMRP.The performance we obtained has similar 
shapes to those obtained on PARSEC[LGC99], 
although the values are slightly less in 
magnitude.This might be because of the followin 
greasons: 

® The simulators used in the studies 
aredifferent,sothepeculiaritiesoftherespecti vesimulato 
rsmighthaveinfluencedtheresults. 

® The scenarios might be different since we 
usedifferenttoolstogeneratethescenarios 


®Theimplementationoftheprotocol mightbediffer. 
Thedifferencesmightoccur primarily in the 
interpretation of 
thefeaturesnotprecisel yspecifiedinthespecification. 


®Theremi ghtalsobedifferencesinthecomputationofthe 
performancemetrics. 


8 Relatedwork: 


Protocol designers of core assisted mesh 
protocol(CAMP)[GM99]andODMRPhaveperformed 
simulationstudiesoftheirprotocols.Simulationstudies 
in [GM99],[MG99a]and [MG99b] use 
asimplifiedsimulators. Aperfectchannel wasassumedan 
dradiopropagation wasnotconsidered 


.FAMA[FG97] wasused as the medium 
accessprotocol, whichisdifferentfromIEEE802. | 1 [IEE 
E97] F the standard MAC protocol 
forwirelessLAN, thatweuseinoursimulation.Onlyasma 
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Ilportionofnetworkhostshadmobility intheirstudy 
where as 
inourcases,allthenodesaremobile, Thecriticalnodesfor 
CAMPperformance,however,remainedstationary. All 
the nodes in [GM99],[MG99a] and[MG99b] were 
multicast session members 
»whichisnotrealisticintypicalmulticastapplications.Th 
enetworktrafficloadwasextremelylight.Informationon 
datasize,radiopropagationrange,orsimulationterrainra 
ngewerenotgiven. Thustheresultsin[GM99],[MG99a] 

and [MG99b]are somewhatlimited .In [LSHGBOO] a 


more realistic 
channelwasmodeledand802. 1 1 wasusedasM ACprotoc 
ol . The simulation studies were carried 
outonPARSEC[BM98]. 

Fouradhocwirelessmulticastprotocolswereevaluated 
and it was concluded that mesh 


basedprotocolsoutperformtreebasedprotocolsingenera 
landODMR Poutperformedall. In[LSHGB00],allnodes 
movedatapredefinedspeed without any pause.Our 
scenario is differentin that each node, after arriving at 
a 
destinationpausesforarandomtimebeforestartingto war 
dsa 

new destination. In [BLGOO] the unicast 
performanceofODMRPhasbeenevaluatedonatestbedo 
flaptops. 


9 Conclusion: 

Overhead. WefoundthatODMRPperforms well in most 
of our scenarios. The performancecurve we obtained 
have similar shapes to thoseobtained on PARSEC 


[LGC99] 3 although ourvalues 
areslightlylessinmagnitude. 
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